Ring 0, a Developer's view Largely discussed in recent trade magazines (PC Week, 2/12/90) is the folly of Novell's choice to use Ring 0 memory protection, also known as Privilege Level 0. In all honesty it is possible to create an application which will "crash" any file server, NetWare not withstanding. But the term "crash" is loosely defined. Throughout the NetWare commentaries I've viewed, it is presumed that NetWare 386 is the first NetWare version designed to run all applications at ring 0. Rather, the first to run server-based applications at ring 0 was NetWare 286 v2.1, first delivered in 1987. These applications were called VAPs (Value Added Processes, NetWare 386 terms such applications NLMs or NetWare Loadable Modules). If one were to analyze what VAPs (though, commercially they number fewer than a 100) have done in the way of crashing NetWare 286 servers, then a taste of the future might be at hand. But, in your review, be sure to realize the relative difficulty of creating a VAP versus creating an NLM. What does ring 0 protection actually provide? In all honesty, not much. Let's take a big for instance, DOS applications all run at ring 0. Further, just how many DOS applications have you encountered that actually violated memory of other applications? Other applications include DOS itself, device drivers, TSRs and other DOS programs. Recognizing that developing a NetWare 386 NLM is much like that of creating a DOS application (minus the ability to multithread the code) one would then understand that avoiding the coding of an ill-behaved (i.e. a program that writes over areas of memory which do not belong to it) application is not that difficult. It is understood that an ill-behaved NLM could cause more chaos that an ill-behaved DOS application, but not necessarily. We have already been witness to what damage viruses from the DOS world can do to files on a LAN. The worst that an ill-behaved NLM could do is erase your network volumes. This worry is much negated by a consistent and implemented backup strategy. But let's face facts. We developers are not creating applications that will destroy or damage your system. With the current concern over memory protection issues we will, more than likely, be utterly careful in the coding of our NLMs. After all, we make our living from their success. And with coding differences between NLMs and DOS applications being relatively small, those successful at creating DOS applications should be able to do the same with NLMs. I'd like to point out another fact in the ring x memory protection concern. Surprise, OS/2 itself is not completely safe. Device drivers written for OS/2 run at ring 2 and applications at ring 3. This means that a carelessly written device driver, perhaps for a disk drive, can overwrite an application's memory thus reducing or eliminating its usefulness. Let me point out that there are 4 rings of protection for the current line of Intel 80x86 CPUs. These rings number 0 through 3. Essentially, an application has access rights to memory at its ring level and those levels beneath it. For instance, ring 3 is beneath ring 2, which is below ring 1 which is below ring 0. I would like to offer a concern that is more likely to be an issue, once server-based applications begin to show up in bulk. That issue is that of CPU scheduling. OS/2 operates with the default that an application does not schedule itself and thus does not have control over when it will execute. This can create programming problems that must be endured by the application developer. Since they have no control of when their application will be running, they can not make simple assumptions that would be possible otherwise. Assumptions such as timeliness of execution, current state of memory and its values, and other caveats that would be more the domain of a programmer's journal than this periodical. However, under OS/2, because of its preemptive scheduling (i.e. applications do not schedule themselves), all applications are guaranteed CPU time and thus an equal chance to execute. With NetWare 386 (as well as 286), scheduling is non-preemptive, i.e. each application is free to run till completion or it may schedule its own preemption. Because of this, it is possible for a NetWare 386 server-based applications to run through long sections without giving up the CPU. The application might give up control of the CPU in order to allow execute-time for other applications, including the server operating system itself. By following a few fundamental rules, NLMs can be designed and coded to allow for appropriate preemptive breaks without disturbing its own execution or delaying that of others. In fact, Novell may, if not already, implement such preemptive breaks each time a library routine is called. Under NetWare 386 (unlike NetWare 286), NLMs all call the same set of Novell supplied library routines. It is these routines where Novell may decide to implement breaks such that performance of a current application is not adversely affected and other applications are given CPU time. Consequently, NetWare 286's VAPs would not benefit from such changes, primarily due to the lack of a common set of library routines. As noted above, the question of performance not memory protection should be the focus of your commentators. It is true that OS/2 with is general purpose operating system design, will, given the same conditions run slower than a LAN OS designed to meet the high performance needs of a LAN environment. However, in a non-preemptive OS such as NetWare 386, there exists the ability for an NLM to run "till completion" without giving up the CPU for other applications to execute. But, with the implementation of a few basic rules governing program execution, any undue performance penalty an NLM could introduce can be circumvented. With OS/2 the performance penalty remains and is not under the control of a developer. Some could retort by saying an NLM developer wishing to get the most performance from their NLM may resort to CPU dominance, rather than following guidelines for preemptive programming. In reply, there are three strategies, one, users themselves may note a marked decrease in system performance upon the use of such an NLM. And, noting such a decrease, will likely call the vendor to find out what is going on, if indeed this is a concern, request appropriate changes be made. Second, as noted earlier, Novell may decide to code preemptive breaks in their library routines. Please note the fact that an NLM will not have much work to perform if it is not, somehow, using these library routines, hence the effectiveness of placing preemption techniques in the library routines. However, it is possible for an NLM to "sit and wait", thus, consuming CPU time without doing any library calls, so the insertion of preemption routines in the library can not be 100% effective. Third, such a situation (where an NLM controls CPU time for an extended amount of time) can be detected and Novell may opt to include routines to detect such occurrences. Processes that incur a large amount of contiguous CPU time could be noted and, at the discretion of the LAN administrator, may be removed from the system. In retrospect, I have been developing NLMs since June of 1989 and have not run into trouble of my NLM overwriting memory outside its definition, likewise, this is true of the VAPs I have written, which date back to 1988. However, I have had performance handicaps incurred due to the lack of my NLM (or VAP) sufficiently preempting itself. Thus the foundation for my lack of concern for "ring 0" protection. John T. McCann Systems R&D Brightwork Development I can be reached through CompuServe @ 70007,3430 or on the Internet at 70007.3430@compuserve.com